Caution: Large numbers of services greatly increase the complexity of management and may impact overall system performance (i.e. resulting from such things as system handoffs). Therefore, it is recommended that a large number of services only be configured if your application absolutely requires it. Please contact your local service representative for more information.
Caution: Even though service names can be identical to those configured in different contexts on the same system, this is not a good practice. Having services with the same name can lead to confusion, difficulty in troubleshooting the problems, and make it difficult to understand outputs of show commands.
Important: Not all commands and keywords/variables are available or supported. This depends on the platform type and the installed license(s).Cisco PID [ ASR5K-00-CSXXDYNR ] Dynamic Radius Extensions (CoA and PoD), or Starent Part Number [ 600-00-7518 ] Dynamic Radius Extensions (CoA and PoD).
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
The system supports CoA messages from the AAA server to change data filters associated with a subscriber session. The CoA request message from the AAA server must contain attributes to identify NAS and the subscriber session and a data filter ID for the data filter to apply to the subscriber session. The filter-id attribute (attribute ID 11) contains the name of an Access Control List (ACL). For detailed information on configuring ACLs, refer to the IP Access Control Lists chapter in the Cisco ASR 5000 Series System Administration Guide.
Important: Changing ACL and rulebase together in a single CoA is not supported. For this, two separate CoA requests can be sent through AAA server requesting for one attribute change per request.|
Step 1
|
|
Step 2
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
Step 3
|
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands. Not all commands and keywords/variables are available or supported. This depends on the platform type and the installed license(s). context <context_name>
radius change-authorize-nas-ip <ipv4/ipv6_address>
|
•
|
<context_name> must be the name of the AAA context where you want to enable CoA and DM. The AAA context must have been configured as described in the Configuring Context-Level AAA Functionality section of the Cisco ASR 5000 Series AAA and GTP Interface Administration and Reference.
|
|
•
|
A number of optional keywords and variables are available for the radius change-authorize-nas-ip command. For more information regarding this command please refer to the Cisco ASR 5000 Series Command Line Interface Reference.
|
|
•
|
Filter-ID: CoA only. This must be the name of an existing Access Control List. If this is present in a CoA request, the specified ACL is immediately applied to the specified subscriber session. The Context Configuration mode command, radius attribute filter-id direction, controls in which direction filters are applied.
|
The following error cause is sent in ACK messages upon successful completion of a CoA or DM request:
An ACL rule named readdress server supports redirection of subscriber sessions. The ACL containing this rule must be configured in the destination context of the user. Only TCP and UDP protocol packets are supported. The ACL rule allows specifying the redirected address and an optional port. The source and destination address and ports (with respect to the traffic originating from the subscriber) may be wildcarded. If the redirected port is not specified, the traffic will be redirected to the same port as the original destination port in the datagrams. For detailed information on configuring ACLs, refer to the IP Access Control Lists chapter in the Cisco ASR 5000 Series System Administration Guide. For more information on readdress server, refer to the ACL Configuration Mode Commands chapter of the Cisco ASR 5000 Series Command Line Interface Reference.
An ACL with the readdress server rule is applied to an existing subscriber session through CoA messages from the RADIUS server. The CoA message contains the 3GPP2-Correlation-ID, User-Name, Acct-Session-ID, or Framed-IP-Address attributes to identify the subscriber session. The CoA message also contains the Filter-Id attribute which specifies the name of the ACL with the readdress server rule. This enables applying the ACL dynamically to existing subscriber sessions. By default, the ACL is applied as both the input and output filter for the matching subscriber unless the Filter-Id in the CoA message bears the prefix in: or out:.
For information on CoA messages and how they are implemented in the system, refer to the RADIUS Change of Authorization and Disconnect Message section.
Important: Changing ACL and rulebase together in a single CoA is not supported. For this, two separate CoA requests can be sent through AAA server requesting for one attribute change per request.Appendix B
GRE Protocol Interface
GRE Protocol Interface
Important: The features described in this chapter is an enhanced feature and need enhanced feature license. This support is only available if you have purchased and installed particular feature support license on your chassis.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
|
•
|
Cisco PID [ ASR5K-00-CS01GRET ] GRE Interface Tunneling, 1K Sessions, or Starent Part Number [ 600-00-7862 ] GRE Interface Tunneling, 1K Sessions.
|
|
•
|
Cisco PID [ ASR5K-00-CS10GRET ] GRE Interface Tunneling, 10K Sessions, or Starent Part Number [ 600-00-7861 ] GRE Interface Tunneling, 10K Sessions.
|
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Important: This section provides the minimum instruction set to enable the GRE Protocol Interface support functionality on a GGSN or P-GW. Commands that configure additional functions for this feature are provided in the Cisco ASR 5000 Series Command Line Interface Reference.These instructions assume that you have already configured the system level configuration as described in Cisco ASR 5000 Series System Administration Guide and specific product Administration Guide.
|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
|
Step 5
|
|
Step 6
|
|
Step 7
|
Save the changes to system configuration by applying the example configuration given in Verifying and Saving Your Configuration chapter.
|
|
Step 8
|
Verify configuration of GRE and VRF related parameters by applying the commands provided in the Verifying Your Configuration section of this chapter.
|
context <vpn_context_name> -noconfirm ]
ip vrf <vrf_name>
ip maximum-routes <max_routes>
|
•
|
<vpn_context_name> is the name of the system context you want to use for VRF. For more information, refer System Administration Guide.
|
|
•
|
|
•
|
<vrf_name> is name of the VRF which is to be associated with various interfaces.
|
|
•
|
context <vpn_context_name>
ip interface <intfc_name> tunnel
ip vrf forwarding <vrf_name>
ip address <internal_ip_address/mask>
source interface <non_tunn_intfc_to_corp>
destination address <global_ip_address>
|
•
|
<vpn_context_name> is the name of the system context you want to use for GRE interface configuration. For more information, refer Cisco ASR 5000 Series Command Line Interface Reference.
|
|
•
|
<intfc_name> is name of the IP interface which is defined as a tunnel type interface and to be used for GRE tunnel interface.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for VRF forwarding.
|
|
•
|
<non_tunn_intfc_to_corp> is the name a non-tunnel interface which is required by system as source interface and preconfigured. For more information on interface configuration refer System Administration Guide.
|
|
•
|
<global_ip_address> is a globally reachable IP address to be used as a destination address.
|
context <vpn_context_name>
ip vrf <vrf_name>
network <internal_ip_address/mask>
|
•
|
<vpn_context_name> is the name of the system context you want to use for OSPF routing. For more information, refer Routing in this guide.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for OSPF routing.
|
context <vpn_context_name>
aaa group <aaa_server_group>
ip vrf <vrf_name>
|
•
|
<vpn_context_name> is the name of the system context you want to use for IP pool and AAA server group.
|
|
•
|
<ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.
|
|
•
|
<aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for IP pool.
|
context <vpn_context_name>
ip address pool name <ip_pool_name>
|
•
|
<vpn_context_name> is the name of the system context you want to use for APN configuration.
|
|
•
|
<ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.
|
|
•
|
<aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
context <vpn_context_name>
|
•
|
<vpn_context_name> is the name of the system context you want to use for static route configuration.
|
|
•
|
<internal_ip_address/mask> is the network IP address with sub-net mask to be used as static route.
|
|
•
|
<tunnel_intfc_name> is name of a predefined tunnel type IP interface which is to be used for GRE tunnel interface.
|
|
•
|
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
|
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.|
Step 1
|
The output of this command displays the configuration of the all interfaces configured in a context.
|
Step 2
|
Appendix C
Gx Interface Support
Gx Interface Support
|
•
|
|
•
|
Important: In addition to standard Gx interface functionality, the Gx interface implemented here provides support of SBLP with additional AVPs in custom DPCA dictionaries. For more information on customer-specific support contact your local technical support representative. In view of required flow bandwidth and QoS, the system provides enhanced support for use of Service Based Local Policy (SBLP) to provision and control the resources used by the IMS subscriber. SBLP is based on the dynamic parameters such as the media/traffic flows for data transport, network conditions and static parameters, such as subscriber configuration and category. It also provides Flow-based Charging (FBC) mechanism to charge the subscriber dynamically based on content usage. With this additional functionality, the Cisco Systems Gateway can act as an Enhanced Policy Decision Function (E-PDF).Cisco PID [ ASR5K-00-CS01PIF ] Policy Interface, 1K sessions, or Starent Part Number [ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature.
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
The Rel 6. Gx interface support is based on the following standards and request for comments (RFCs):
|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 5
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands. context <context_name>
ims-auth-service <imsa_service_name>
p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> }
diameter origin endpoint <endpoint_name>
diameter dictionary <dictionary>
failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <host_name> [ realm <realm_name> ] [ secondary host <host_name> [ realm <realm_name> ] ]
diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
|
•
|
<context_name> must be the name of the context where you want to enable IMS Authorization Service.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization Service to be configured for the Gx interface authentication.
|
|
•
|
Secondary P-CSCF IP address can be configured in the P-CSCF table. Refer to the Cisco ASR 5000 Series Command Line Interface Reference for more information on the p-cscf table command.
|
|
•
|
Optional: To configure the quality of service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:
|
qos-update-timeout <timeout_duration>
|
•
|
Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
|
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]
|
•
|
Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:
|
|
•
|
Optional: To configure the algorithm to select Diameter host table, in the Policy Control Configuration Mode, enter the following command:
|
diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
|
Step 1
|
context <context_name>
show ims-authorization service name <imsa_service_name>
context <context_name>
apn <apn_name>
ims-auth-service <imsa_service_name>
|
•
|
<context_name> must be the name of the context in which the IMS Authorization service was configured.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication in the context.
|
show subscribers ims-auth-service <imsa_service_name>
<imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication.
|
•
|
|
•
|
|
•
|
Cisco PID [ ASR5K-00-CS01PIF ] Policy Interface, 1K sessions, or Starent Part Number [ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature.
|
|
•
|
Cisco PID [ ASR5K-00-CS01ECG2 ] Enhanced Charging Bundle 2 1k Sessions, or Starent Part Number [ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — To enable and configure Diameter and ECS functionality.
|
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
|
•
|
Binding: Binding is the generation of an association between a Service Data Flow (SDF) and the IP CAN bearer (for GPRS a PDP context) transporting that SDF.
|
|
•
|
Gating Control: Gating control is the blocking or allowing of packets, belonging to an SDF, to pass through to the desired endpoint. A gate is described within a PCC rule and gating control is applied on a per SDF basis. The commands to open or close the gate leads to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed, all packets of the related IP flows are dropped. If the gate is opened, the packets of the related IP flows are allowed to be forwarded.
|
|
•
|
Event Reporting: Event reporting is the notification of and reaction to application events to trigger new behavior in the user plane as well as the reporting of events related to the resources in the Gateway (PCEF).
|
Important: In this release, event triggers “IP-CAN_CHANGE” and “MAX_NR_BEARERS_REACHED” are not supported.|
•
|
QoS Control: QoS control is the authorization and enforcement of the maximum QoS that is authorized for a SDF or an IP-CAN bearer or a QoS Class Identifier (QCI). In case of an aggregation of multiple SDFs (for GPRS a PDP context), the combination of the authorized QoS information of the individual SDFs is provided as the authorized QoS for this aggregate.
|
Important: In this release, QoS Resource Reservation is not supported.
Important: In this release, coordination of authorized QoS scopes in mixed mode (BCM = UE_NW) is not supported.
Important: In 11.0 and later releases Rule-Activation-Time / Rule-Deactivation-Time / Revalidation-Time AVP is successfully parsed only if its value corresponds to current time or a later time than the current IPSG time, else the AVP and entire message is rejected. In earlier releases the AVP is successfully parsed only if its value corresponds to a later time than the current IPSG time, else the AVP and entire message is rejected.
Important: In this release, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.
Important: A third type of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
Important: In earlier releases, ECS used only the Priority-Level part of ARP byte for bearer binding, (along with QCI). Now the entire ARP byte is used for bearer binding (along with QCI). Since the capability and vulnerability bits are optional in a dynamic rule, if a dynamic rule is received without these flags, it is assumed that the capability bit is set to 1 (disabled) and vulnerability bit is set to 0 (enabled). For predefined rules, currently configuring these two flags is not supported, so as of now all predefined rules are assumed to have capability bit set to 1 (disabled) and vulnerability bit set to 0 (enabled).
Important: In this release, configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
Important: In 11.0 and later releases, the maximum valid length for a charging rule name is 63 bytes. When the length of the charging rule name is greater than 63 bytes, a charging rule report with RESOURCES_LIMITATION as Rule-Failure-Code is sent. This charging rule report is sent only when the length of the rule name is lesser than 128 characters. When the charging rule name length is greater than or equal to 128 characters no charging rule report will be sent. In earlier releases, the length of the charging rule name constructed by PCRF was limited to 32 bytes.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
Important: In 11.0 and later releases, IMSA and ECS allow the PCRF to install two (or more) dynamic rules with the same precedence value. In earlier releases, for two distinct dynamic rules having the same precedence the second rule used to be rejected.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.Cisco PID [ ASR5K-00-CS01CHGX ] Charging Over Gx, 1K sessions, or Starent Part Number [ 600-00-7822 ] Charging Over Gx.
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
|
Step 1
|
|
Step 3
|
|
Step 5
|
Optional: Configure the Volume Reporting over Gx feature as described in the Configuring Volume Reporting over Gx section.
|
|
Step 6
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands. context <context_name>
ims-auth-service <imsa_service_name>
p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> } [ secondary { address <ip_address> | ipv6-address <ipv6_address> } ]
diameter origin endpoint <endpoint_name>
diameter dictionary <dictionary>
diameter request-timeout <timeout_duration>
diameter host-select row-precedence <precedence_value> table { { { 1 | 2 } host <host_name> [ realm <realm_id> ] [ secondary host <host_name> [ realm <realm_id> ] ] } | { prefix-table { 1 | 2 } msisdn-prefix-from <msisdn_prefix_from> msisdn-prefix-to <msisdn_prefix_to> host <host_name> [ realm <realm_id> ] [ secondary host <sec_host_name> [ realm <sec_realm_id> ] algorithm { active-standby | round-robin } ] } } [ -noconfirm ]
failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
|
•
|
<context_name> must be the name of the context where you want to enable IMS Authorization service.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization service to be configured for Rel. 7 Gx interface authentication.
|
To enable the Gx interface to connect to a specific PCRF for a range of subscribers configure msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the starting and ending MSISDNs respectively.
To enable the Gx interface to connect to a specific PCRF for a specific subscriber, configure both msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the same MSISDN.
|
•
|
Optional: To configure the Quality of Service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:
|
qos-update-timeout <timeout_duration>
|
•
|
Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
|
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]
|
•
|
Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:
|
|
•
|
To configure the PCRF host destinations configured in the GGSN/PCEF, use the diameter host-select CLI commands.
|
|
•
|
To configure the GGSN/PCEF to use a pre-defined rule when the Gx fails, set the failure-handling cc-request-type CLI to continue. Policies available/in use will continue to be used and there will be no further interaction with the PCRF.
|
active-charging service <ecs_service_name>
charging-action <charging_action_name>
active-charging service <ecs_service_name>
rulebase <rulebase_name>
|
Step 1
|
context <context_name>
show ims-authorization service name <imsa_service_name>
Use the following example to apply IMS Authorization service functionality to a previously configured APN within the context configured in the Configuring Rel. 7 Gx Interface section.
context <context_name>
apn <apn_name>
ims-auth-service <imsa_service_name>
active-charging rulebase <rulebase_name>
|
•
|
<context_name> must be the name of the context in which the IMS Authorization service was configured.
|
|
•
|
<imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication in the context.
|
show subscribers ims-auth-service <imsa_service_name>
<imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication.
active-charging service <ecs_service_name>
rulebase <rulebase_name>
action priority <priority> dynamic-only ruledef <ruledef_name> charging-action <charging_action_name> monitoring-key <monitoring_key>
context <context_name>
ims-auth-service <imsa_service_name>
|
•
|
The event-update CLI which enables volume usage report to be sent in event updates is available only in 10.2 and later releases. The optional keyword reset-usage enables to support delta reporting wherein the usage is reported and reset at PCEF. If this option is not configured, the behavior is to send the usage information as part of event update but not reset at PCEF.
|
|
•
|
Cisco PID [ ASR5K-00-CS01PIF ] Policy Interface, 1K sessions, or Starent Part Number [ 600-00-7585 ] Dynamic Policy Interface — license for IMS Authorization Service feature.
|
|
•
|
Cisco PID [ ASR5K-00-CS01ECG2 ] Enhanced Charging Bundle 2 1k Sessions, or Starent Part Number [ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — To enable and configure Diameter and ECS functionality.
|
|
•
|
Important: Unconditional reporting of event triggers from PCRF to PCEF when PCEF has not requested for is not supported.
Important: In the HA/PDSN Rel. 8 Gx implementation, only the AN_GW_CHANGE (21) event trigger is supported.
Important: In the HA/PDSN Rel. 8 Gx implementation, only authorized IP-CAN Session is supported. Provisioning of authorized QoS per IP-CAN bearer, policy enforcement for authorized QoS per QCI, and coordination of authorized QoS scopes in mixed mode are not applicable.|
•
|
Important: In the HA/PDSN Rel. 8 Gx implementation, offline charging is not supported.
Important: In the HA/PDSN Rel. 8 Gx implementation, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.
Important: A third kind of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
Important: Configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
|
3.
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands. context <context_name>
ims-auth-service <imsa_service_name>
diameter origin endpoint <endpoint_name>
diameter dictionary <dictionary>
diameter request-timeout <timeout_duration>
diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <primary_host_name> [ realm <primary_realm_id> ] [ secondary host <secondary_host_name> [ realm <secondary_realm_id> ] ] [ -noconfirm ]
failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
origin realm <realm_name>
response-timeout <timeout_duration>
connection timeout <timeout_duration>
connection retry-timeout <timeout_duration>
peer <secondary_peer_name> [ realm <secondary_realm_name> ] address <ip_address> [ port <port_number> ]
|
•
|
<context_name> must be the name of the context where you want to enable IMSA service.
|
|
•
|
<imsa_service_name> must be the name of the IMSA service to be configured for Rel. 8 Gx interface authentication.
|
|
•
|
To configure the PCEF to use a pre-defined rule when the Gx fails, set the failure-handling cc-request-type CLI to continue. Policies available/in use will continue to be used and there will be no further interaction with the PCRF.
|
context <context_name>
show ims-authorization service name <imsa_service_name>
context <context_name>
encrypted password <encrypted_password>
ims-auth-service <imsa_service_name>
ip context-name <context_name>
mobile-ip home-agent <ip_address>
active-charging rulebase <rulebase_name>
|
•
|
<context_name> must be the name of the context in which the IMSA service was configured.
|
|
•
|
<imsa_service_name> must be the name of the IMSA service configured for IMS authentication in the context.
|
show subscribers ims-auth-service <imsa_service_name>
<imsa_service_name> must be the name of the IMSA service configured for IMS authentication.
Cisco PID [ ASR5K-00-CS01CHGX ] Charging Over Gx, 1K sessions, or Starent Part Number [ 600-00-7822 ] Charging Over Gx.
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
Cisco PID [ ASR5K-00-CS01CHGX ] Charging Over Gx, 1K sessions, or Starent Part Number [ 600-00-7822 ] Charging Over Gx.
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
Appendix D
Gy Interface Support
Gy Interface Support
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
Cisco PID [ ASR5K-00-CS01ECG2 ] Enhanced Charging Bundle 2, 1K Sessions, or Starent Part Number [ 600-00-7574 ] Enhanced Charging Bundle 2 1k Sessions — To enable and configure Diameter and DCCA/Gy functionality with ECS.
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
Important: Online charging for events (“Immediate Event Charging” and “Event Charging with Reservation”) is not supported. Only “Session Charging with Reservation” is supported.
Important: Decentralized Rating is not supported in this release. Decentralized Unit determination is done using CLI configuration.
Important: Immediate Event Charging is not supported in this release. “Reserve Units Request” and “Reserve Units Response” are done for Session Charging and not for Event Charging.
Important: Cost-Information, Remaining-Balance, and Low-Balance-Indication AVPs are not supported.
Important: Acct-Application-Id is not parsed and if sent will be ignored by the PCEF/GW. In case the Result-Code is not DIAMETER_SUCCESS, the connection to the peer is closed.
Important: DWR is sent only after Tw expiry after the last message that came from the server. Say if there is continuous exchange of messages between the peers, DWR might not be sent if (Current Time - Last message received time from server) is less than Tw.
Important: Restricting usages based on CC-Input-Octets and CC_Output-Octets is not supported in this release.If the MSCC AVP is missing in CCA-Update it is treated as invalid CCA and the session is terminated.
Important: In this release, Gy triggers are not supported for HA.
Important: In this release, Gy does not support UNIT_INDETERMINATE value.
Important: FUI AVP at command level is only supported for Terminate action.|
•
|
For more information on recovery mechanisms, please refer to the Cisco ASR 5000 Series System Administration Guide.
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
|
3.
|
Verify and save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Cisco ASR 5000 Series Command Line Interface Reference for complete information regarding all commands. context <context_name>
diameter endpoint <endpoint_name>
origin realm <realm>
active-charging service <ecs_service_name>
diameter origin endpoint <endpoint_name>
diameter pending-timeout <timeout_period>
diameter dictionary <dictionary>
context <context_name>
apn <apn_name>
ims-auth-service <service>
ip context-name <context_name>
active-charging rulebase <rulebase_name>
credit-control-group <cc_group_name>
|
•
|
For information on configuring IP access lists, refer to the Access Control Lists chapter in the Cisco ASR 5000 Series System Administration Guide.
|
|
•
|
For more information on configuring ECS ruledefs, refer to the ACS Ruledef Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.
|
|
•
|
For more information on configuring ECS charging actions, refer to the ACS Charging Action Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.
|
|
•
|
For more information on configuring ECS rulebases, refer to the ACS Rulebase Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.
|
context <context_name>
diameter endpoint <endpoint_name>
origin realm <realm>
active-charging service <ecs_service_name>
ruledef <ruledef_name>
charging-action <charging_action_name>
content-id <content_id>
cca charging credit rating-group <rating_group>
rulebase <rulebase_name>
diameter origin endpoint <endpoint_name>
diameter pending-timeout <timeout>
diameter dictionary <dictionary>
context <context_name>
ip context-name <context_name>
active-charging rulebase <rulebase_name>
credit-control-group <cc_group_name>
|
•
|
For information on configuring IP access lists, refer to the Access Control Lists chapter in the Cisco ASR 5000 Series Systems Administration Guide.
|
|
•
|
For more information on configuring ECS ruledefs, refer to the ACS Ruledef Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.
|
|
•
|
For more information on configuring ECS charging actions, refer to the ACS Charging Action Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.
|
|
•
|
For more information on configuring ECS rulebases, refer to the ACS Rulebase Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.
|
|
show active-charging credit-control session-states [ rulebase <rulebase_name> ] [ content-id <content_id> ]
|
Appendix E
ICAP Interface Support
ICAP Interface Support
|
•
|
Cisco PID [ ASR5K-00-CS01ICAP ] Content Filtering ICAP Interface, 1K sessions, or Starent Part Number [ 600-00-7578 ] Content Filtering ICAP Interface, 1K sessions.
|
|
•
|
Cisco PID [ ASR5K-00-CS10ICAP ] Content Filtering ICAP Interface, 10K Sessions, or Starent Part Number [ 600-00-8530 ] Content Filtering ICAP Interface, 10K Sessions.
|
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
|
•
|
|
•
|
|
•
|
Important: This section provides the minimum instruction set for configuring external content filtering servers on ICAP interface on the system. For more information on commands that configure additional parameters and options, refer to CFSG Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
Optional. Configure the charging action to forward HTTP/WAP GET request to external content filtering servers on ICAP interface in Active Charging Configuration mode by applying the example configuration in the Configuring Charging Action for ICAP Server Group section.
|
|
Step 5
|
|
Step 6
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
origin address <ip_address>
|
•
|
<ip_address> is local IP address of the CFSG endpoint.
|
context <icap_context_name>
content-filtering server-group <icap_server_grp_name>
deny-message <msg_string>
response-timeout <timeout>
connection retry-timeout <retry_timeout>
failure-action {allow | content-insertion <content_string> | discard | redirect-url <url> | terminate-flow}
|
•
|
The maximum outstanding request per ICAP connection configured using the optional max <max_msgs> keyword is limited to one. Therefore, any other value configured using the max keyword will be ignored.
|
|
•
|
Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:
|
content-filtering mode server-group <cf_server_group>
|
•
|
In StarOS 8.1, the optimized-mode keyword enables ACS in the Optimized mode, wherein ACS functionality is managed by SessMgrs. In StarOS 8.1, ACS must be enabled in the Optimized mode.
|
|
•
|
In StarOS 8.3, the optimized-mode keyword is obsolete. With or without this keyword ACS is always enabled in Optimized mode.
|
|
•
|
In StarOS 8.0 and StarOS 9.0 and later, the optimized-mode keyword is not available.
|
active-charging service <acs_svc_name>
This section explains how to display and review the configurations after saving them in a .cfg file as described in Verifying and Saving Your Configuration chapter of this guide and also to retrieve errors and warnings within an active configuration for a service.
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.The following is a sample output. In this example, an ICAP Content Filtering server group named icap_cfsg1 was configured.
|
Step 2
|
Appendix F
IP Pool Sharing Protocol
IP Pool Sharing Protocol
|
•
|
|
•
|
For graceful termination conditions (e.g. an administrative user issues the reload command), sends a termination message to the secondary HA causing it to assume the responsibilities of the primary HA until the primary is available again.
|
|
•
|
For graceful termination conditions (e.g. an administrative user issues the reload command), it notifies the primary HA that it is going out of service
|
|
•
|
|
•
|
New sessions: Once IPSP is configured, new sessions are directed to a secondary HA (HA2) allowing the primary HA to go through a software upgrade without degrading network capacity. The secondary HA requests addresses from the primary HA’s (HA1) pools as needed. As the addresses are allocated, they are busied out on the primary HA. This procedure is displayed below.
|
|
•
|
Session handoffs: Once IPSP is configured, sessions originally registered with the primary HA (HA1) are re-registered with the secondary HA (HA2). To ensure the session is assigned the same IP address, the secondary HA requests the address from the primary HA. The primary HA verifies the binding and releases it to the secondary HA which, in turn, re-assigns it to the session. As the addresses are allocated, they are busied out on the primary HA. This procedure is displayed below.
|
This section provides information and instructions for configuring IPSP before the software upgrade.
Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer to the IPSP Configuration Mode Commands chapter in the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
Configure an interface on the system for use by IPSP according to the instructions found in the Creating and Configuring Ethernet Interfaces and Ports section of the System Administration Guide.
|
|
Step 3
|
|
Step 4
|
Perform the boot system priority and SPC/SMC card synchronization as described in Off-line Software Upgrade section in the System Administration Guide.
|
|
Step 5
|
|
Step 6
|
Verify your ACL configuration by following the steps in the Verifying the IPSP Configuration section.
|
|
Step 7
|
Proceed for software upgrade as described in Off-line Software Upgrade section in the System Administration Guide.
|
|
Step 8
|
Save your configuration as described in the Saving Your Configuration chapter.
|
Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer to the IPSP Configuration Mode Commands chapter in Command Line Interface Reference.|
•
|
ipsp_if_name is the name of the interface on which you want to enable IPSP.
|
Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer to the IPSP Configuration Mode Commands chapter in the Command Line Interface Reference.|
•
|
ipsp_if_name is the name of the interface on which you want to enable IPSP.
|
Important: Once this configuration is done, the primary HA begins to hand responsibility for sessions and release IP addresses to the secondary HA. Prior to performing the software upgrade, all IP addresses must be released. When IPSP has released all IP pool addresses from the primary HA an SNMP trap (starIPSPAllAddrsFree) is triggered. The output of this command provides the list of used addresses and released addresses. The system will send the starIPSPAllAddrsFree trap once all IP addresses are released. When the value in the Used Addresses column reaches 0 for all IP pools listed, then the primary HA sends the SNMP trap and notifies the secondary HA to take over as the primary HA.
Important: It is important to note that the HA that was originally designated as the secondary is now functioning as the primary HA. Conversely, the HA that was originally designated as the primary is now functioning as the secondary.
Important: This section provides the minimum instruction set for configuring IPSP on the system. For more information on commands that configure additional parameters and options, refer IPSP Configuration Mode Commands chapter in Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
|
Step 5
|
Verify your ACL configuration by following the steps in the Verifying the IPSP Configuration section.
|
|
Step 6
|
Save your configuration as described in the Saving Your Configuration chapter.
|
Caution: Prior to disabling IPSP, ensure that the primary HA has released all IP addresses to secondary HA.
Important: This section provides the minimum instruction set for disabling IPSP on the HAs. For more information on commands, refer to the IPSP Configuration Mode Commands chapter in the Command Line Interface Reference.|
•
|
ipsp_if_name is the name of the interface on which you want to disable IPSP.
|
Appendix G
IP Header Compression
IP Header Compression
Important: RoHC header compression is not applicable for SGSN and GGSN services.|
•
|
Van Jacobsen (VJ) - The RFC 1144 (CTCP) header compression standard was developed by V. Jacobson in 1990. It is commonly known as VJ compression. It describes a basic method for compressing the headers of IPv4/TCP packets to improve performance over low speed serial links.
|
|
•
|
RObust Header Compression (RoHC) - The RFC 3095 (RoHC) standard was developed in 2001. This standard can compress IP/UDP/RTP headers to just over one byte, even in the presence of severe channel impairments. This compression scheme can also compress IP/UDP and IP/ESP packet flows. RoHC is intended for use in wireless radio network equipment and mobile terminals to decrease header overhead, reduce packet loss, improve interactive response, and increase security over low-speed, noisy wireless links.
|
Important: Use of RoHC requires that a valid RoHC license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Saving Your Configuration chapter.
|
context <ctxt_name>
subscriber name <subs_name>
|
•
|
<ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.
|
|
•
|
<subs_name> is the name of the subscriber in the current context that you want to enable VJ IP header compression for.
|
show subscriber configuration username subs_name
Important: Use of RoHC requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in the Cisco ASR 5000 Series Command Line Interface Reference.|
•
|
|
•
|
|
•
|
Save your configuration as described in the Saving Your Configuration chapter.
|
context <ctxt_name>
subscriber name <subs_name>
ip header-compression RoHC [ any [ mode { optimistic | reliable | unidirectional } ] | cid-mode { { large | small } [ marked-flows-only | max-cid | max-hdr <value> | mrru <value> ] } | marked flows-only | max-hdr <value> | mrru <value> | downlink | uplink ] }+
|
•
|
<ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.
|
|
•
|
<subs_name> is the name of the subscriber in the current context that you want to enable RoHC header compression for.
|
|
•
|
Refer to the Subscriber Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference for more details on this command and its options.
|
show subscriber configuration username subs_name
Important: If both RoHC and VJ header compression are specified, the optimum header compression algorithm for the type of data being transferred is used for data in the downlink direction.
Important: Use of RoHC requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in th Cisco ASR 5000 Series Command Line Interface Reference.|
•
|
|
•
|
|
•
|
Save your configuration as described in the Saving Your Configuration chapter.
|
context <ctxt_name>
subscriber name <subs_name>
ip header-compression vj RoHC [ any [ mode { optimistic | reliable | unidirectional } ] | cid-mode { { large | small } [ marked-flows-only | max-cid | max-hdr <value> | mrru <value> ] } | marked flows-only | max-hdr <value> | mrru <value> | downlink | uplink ] }+
|
•
|
<ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.
|
|
•
|
<subs_name> is the name of the subscriber in the current context that you want to enable RoHC header compression for.
|
show subscriber configuration username subs_name
Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer PDSN Service Configuration Mode Commands or HSGW Service Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.|
Step 1
|
Enable header compression by applying the example configuration in the Enabling ROHC Header Compression with PDSN or Enabling ROHC Header Compression with HSGW section.
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Saving Your Configuration chapter.
|
context <ctxt_name>
pdsn-service <svc_name>
cid-mode {large | small} max-cid integer
mrru <num_octets>
|
•
|
<ctxt_name> is the system context in which PDSN service is configured and you wish to configure the service profile.
|
|
•
|
<svc_name> is the name of the PDSN service in which you want to enable RoHC over SO67.
|
|
•
|
Refer to the PDSN Service RoHC Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference for more details on this command and its options.
|
context <ctxt_name>
hsgw-service <svc_name>
cid-mode {large | small} max-cid integer
mrru <num_octets>
|
•
|
<ctxt_name> is the system context in which HSGW service is configured and you wish to configure the service profile.
|
|
•
|
<svc_name> is the name of the HSGW service in which you want to enable RoHC over SO67.
|
|
•
|
Refer to the HSGW Service RoHC Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference for more details on this command and its options.
|
show configuration context ctxt_name
Important: Use of RoHC requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.
Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.|
Step a
|
Configure RoHC profile by applying the example configuration in the Creating ROHC Profile for Subscriber using Compression Mode section using compression mode.
|
|
Step b
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
Save your configuration as described in the Saving Your Configuration chapter.
|
RoHC-profile profile-name <RoHC_comp_profile_name>
rtp-sn-p <p_value>
|
•
|
<RoHC_comp_profile_name> is the name of the RoHC profile with compression mode which you want to apply to a subscriber.
|
|
•
|
System configured most of the parameters by default. For more information on other options and parameters and details, refer to the RoHC Profile Compression Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.
|
RoHC-profile profile-name <RoHC_decomp_profile_name>
max-jitter-cd <dur_ms>
nak-limit <limit>
optimistic-mode-ack-limit <num_pkts>
piggyback-wait-time <dur_ms>
rtp-sn-p <p_value>
|
•
|
<RoHC_profile_name> is the name of the RoHC profile with decompression mode which you want to apply to a subscriber.
|
|
•
|
System configured most of the parameters by default. For more information on other options and parameters and details, refer to the RoHC Profile Decompression Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.
|
context <ctxt_name>
subscriber name <subs_name>
RoHC-profile-name <RoHC_profile_name>
|
•
|
<ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.
|
|
•
|
<subs_name> is the name of the subscriber in the current context that you want to enable RoHC header compression for.
|
|
•
|
<RoHC_profile_name> is the name of the existing RoHC profile (created with compressed or decompressed mode) which you want to apply to a subscriber in the current context.
|
|
•
|
Refer to the Subscriber Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference for more details on this command and its options.
|
show subscriber configuration username subs_name
Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Saving Your Configuration chapter.
|
context <ctxt_name>
subscriber name <subs_name>
|
•
|
<ctxt_name> is the system context in which you wish to configure the subscriber profile. Typically this is an AAA context.
|
|
•
|
<subs_name> is the name of the subscriber in the current context that you want to disable IP header compression for.
|
show subscriber configuration username <subs_name>
Important: This section provides the minimum instruction set for configuring subscriber profile for header compression. For more information on commands that configure additional parameters and options, refer PDSN Service Configuration Mode Commands or HSGW Service Configuration Mode Commands chapter in Cisco ASR 5000 Series Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Saving Your Configuration chapter.
|
context <ctxt_name>
pdsn/hsgw-service <svc_name>
|
•
|
<ctxt_name> is the system context in which PDSN or HSGW service is configured and you wish to configure the service profile.
|
|
•
|
<svc_name> is the name of the PDSN or HSGW service in which you want to disable RoHC over SO67.
|
show configuration context <ctxt_name>
|
•
|
For more information on these commands, refer to the Cisco ASR 5000 Series Command Line Interface Reference.
Appendix H
IP Security
IP Security
Caution: IPSec parameter configurations saved using this release may not function properly with older software releases.|
•
|
|
•
|
PDN Access: Subscriber IP traffic is routed over an IPSec tunnel from the system to a secure gateway on the packet data network (PDN) as determined by access control list (ACL) criteria. This application can be implemented for both core network service and HA-based systems. The following figure shows IPSec configurations.
|
|
•
|
Mobile IP: Mobile IP control signals and subscriber data is encapsulated in IPSec tunnels that are established between foreign agents (FAs) and home agents (HAs) over the Pi interfaces.
|
Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.|
•
|
L2TP: L2TP-encapsulated packets are routed from the system to an LNS/secure gateway over an IPSec tunnel.
|
As described in the IP Access Control Lists chapter of this guide, ACLs on the system define rules, usually permissions, for handling subscriber data packets that meet certain criteria. Crypto ACLs, however, define the criteria that must be met in order for a subscriber data packet to be routed over an IPSec tunnel.
Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
Important: These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA. In addition, parameters configured using this procedure must be configured in the same destination context on the system.|
•
|
Configure one or more IP access control lists (ACLs) according to the information and instructions located in IP Access Control Lists chapter of this guide.
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
|
The FA determines the appropriate crypto map to use for IPSec protection based on the HA address attribute. It does this by comparing the address received to those configured using the isakmp peer-ha command. From the crypto map, the system determines the following:
|
|||
|
|||
|
The HA determines the appropriate crypto map to use for IPSec protection based on the FA’s address. It does this by comparing the address received to those configured using the isakmp peer-fa command. From the crypto map, the system determines the following:
|
|||
Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
Important: These instructions assume that the systems were previously configured to support subscriber data sessions either as an FA or an HA.|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.|
Step 5
|
|
Step 6
|
|
Step 7
|
|
Step 8
|
|
Step 9
|
Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.|
Step 11
|
|
Step 12
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions and L2TP tunneling either as a PDSN or an HA. In addition, with the exception of subscriber attributes, all other parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
|
Step 5
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
Important: These instructions assume that the system was previously configured to support PDSN compulsory tunneling subscriber data sessions. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
|
Step 5
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
Important: These instructions assume that the system was previously configured to support subscriber PDP contexts and L2TP tunneling either as a GGSN. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
|
Step 5
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
Important: This section provides the minimum instruction set for configuring transform set on your system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Transform Configuration Mode chapters in the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
crypto ipsec transform-set <transform_name> ah hmac { md5-96 | none |sha1-96 } esp hmac { { md5-96 | none | sha1-96 } { cipher {des-cbc | 3des-cbc | aes-cbc } | none }
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the crypto transform set(s).
|
|
•
|
<transform_name> is the name of the crypto transform set in the current context that you want to configure for IPSec configuration.
|
|
•
|
For more information on parameters, refer to the IPSec Transform Configuration Mode Commands chapter in the Command Line Interface Reference.
|
show crypto transform-set transform_name
Important: This section provides the minimum instruction set for configuring ISAKMP policies on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and ISAKMP Configuration Mode Commands chapters in the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP policy.
|
|
•
|
<priority> dictates the order in which the ISAKMP policies are proposed when negotiating IKE SAs.
|
|
•
|
For more information on parameters, refer to the ISAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.
|
Caution: Modification(s) to an existing ISAKMP policy configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
Important: This section provides the minimum instruction set for configuring ISAKMP crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map ISAKMP Configuration Mode chapters in the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.
|
|
•
|
<map_name> is name by which the ISAKMP crypto map will be recognized by the system.
|
|
•
|
<acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.
|
|
•
|
<group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter. For more information, refer to the Redundant IPSec Tunnel Fail-Over section of this chapter.
|
|
•
|
For more information on parameters, refer to the Crypto Map ISAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.
|
show crypto map [ tag map_name | type ipsec-isakmp ]
Caution: Modification(s) to an existing ISAKMP crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
Important: This section provides the minimum instruction set for configuring dynamic crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Dynamic Configuration Mode chapters in the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the dynamic crypto maps.
|
|
•
|
<map_name> is name by which the dynamic crypto map will be recognized by the system.
|
|
•
|
For more information on parameters, refer to the Crypto Map Dynamic Configuration Mode Commands chapter in the Command Line Interface Reference.
|
show crypto map [ tag map_name | type ipsec-dynamic ]
Caution: Modification(s) to an existing dynamic crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
Important: This section provides the minimum instruction set for configuring manual crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Manual Configuration Mode chapters in the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
set session-key { inbound | outbound } { ah <ah_spi> [ encrypted ] key <ah_key> | esp <esp_spi> [ encrypted ] cipher <encryption_key> [ encrypted ] authenticator <auth_key> }
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the manual crypto maps.
|
|
•
|
<map_name> is name by which the manual crypto map will be recognized by the system.
|
|
•
|
<acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.
|
|
•
|
<group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter.
|
|
•
|
For more information on parameters, refer to the Crypto Map Manual Configuration Mode Commands chapter in the Command Line Interface Reference.
|
show crypto map [ tag map_name | type ipsec-manual ]
Caution: Modification(s) to an existing manual crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
Important: This section provides the minimum instruction set for applying manual or ISAKMP crypto maps to an interface on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.|
Step 2
|
|
Step 3
|
|
Step 4
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the system context in which the interface is configured to apply crypto map.
|
|
•
|
<interface_name> is the name of a specific interface configured in the context to which the crypto map will be applied.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypto map.
|
interface 20/6
Important: This section provides the minimum instruction set for configuring an FA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.|
•
|
|
•
|
|
•
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the system context in which the FA service is configured to support IPSec.
|
|
•
|
<fa_svc_name> is name of the FA service for which you are configuring IPSec.
|
|
•
|
<ha_address> is IP address of the HA service to which FA service will communicate on IPSec.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypto map.
|
Important: This section provides the minimum instruction set for configuring an HA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the system context in which the FA service is configured to support IPSec.
|
|
•
|
<ha_svc_name> is name of the HA service for which you are configuring IPSec.
|
|
•
|
<fa_address> is IP address of the FA service to which HA service will communicate on IPSec.
|
|
•
|
<aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypot map.
|
As described in the How the IPSec-based Mobile IP Configuration Works section of this chapter, the system uses attributes stored in a subscriber’s RADIUS profile to determine how IPSec should be implemented.
|
•
|
|
•
|
|
3 : Enables IPSec for tunnels and registration messages
4 : Disables IPSec
|
||
Important: These instructions are required for compulsory tunneling. They should only be performed for attribute-based tunneling if the Tunnel-Service-Endpoint, the SN1-Tunnel-ISAKMP-Crypto-Map, or the SN1 -Tunnel-ISAKMP-Secret are not configured in the subscriber profile.
Important: This section provides the minimum instruction set for configuring an LAC service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> { [encrypted] isakmp-secret <secret> } ] [ description <text> ] [ preference <integer>]
|
•
|
<ctxt_name> is the destination context where the LAC service is configured to support IPSec.
|
|
•
|
<lac_svc_name> is name of the LAC service for which you are configuring IPSec.
|
|
•
|
<lns_address> is IP address of the LNS node to which LAC service will communicate on IPSec.
|
|
•
|
<aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.
|
|
•
|
<map_name> is name of the preconfigured ISAKMP or a manual crypot map.
|
In addition to the subscriber profile attributes listed in the RADIUS and Subscriber Profile Attributes Used section of the L2TP Access Concentrator chapter in this guide, the table below lists the attributes required to support IPSec for use with attribute-based L2TP tunneling.
|
•
|
This section provides the minimum instruction set for configuring an L2TP service on the PDSN system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
context <ctxt_name>
pdsn-service <pdsn_svc_name>
ppp tunnel-context <lac_ctxt_name>
|
•
|
<ctxt_name> is the destination context where the PDSN service is configured.
|
|
•
|
<pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.
|
|
•
|
<lac_ctxt_name> is the name of the destination context where the LAC service is located.
|
context <ctxt_name>
|
•
|
<ctxt_name> is the destination context where the PDSN service is configured.
|
|
•
|
<pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.
|
|
•
|
<lac_ctxt_name> is name of the destination context where the LAC service is located.
|
Important: The peer security gateway must support RFC 3706 in order for this functionality to function properly.|
•
|
Primary Tunnel is down: A primary tunnel that was previously "up" is now "down" representing an error condition.
|
|
•
|
Primary Tunnel is up: A primary tunnel that was previously "down" is now "up".
|
|
•
|
Secondary tunnel is down: A secondary tunnel that was previously "up" is now "down" representing an error condition.
|
|
•
|
Secondary Tunnel is up: A secondary tunnel that was previously "down" is now "up".
|
|
•
|
Fail-over successful: The switchover of user traffic was successful. This is generated for both primary-to-secondary and secondary-to-primary switchovers.
|
|
•
|
Unsuccessful fail-over: An error occurred when switching user traffic from either the primary to secondary tunnel or the secondary to primary tunnel.
|
|
•
|
Important: Parameters configured using this procedure must be configured in the same context on the system.
Important: The system supports a maximum of 32 crypto groups per context. However, configuring crypto groups to use the same loopback interface for secondary IPSec tunnels is not recommended and may compromise redundancy on the chassis.
Important: This section provides the minimum instruction set for configuring crypto groups on the system. For more information on commands that configure additional parameters and options, refer Command Line Interface Reference.|
Step 2
|
|
Step 3
|
|
Step 4
|
|
Step 5
|
|
Step 6
|
|
Step 7
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the destination context where the Crypto Group is to be configured.
|
|
•
|
<group_name> is name of the Crypto group you want to configure for IPSec tunnel failover support.
|
|
•
|
<acl_name> is name of the pre-configured crypto ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. For more information on crypto ACL, refer Crypto Access Control List (ACL) section of this chapter.
|
|
•
|
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.
|
|
•
|
<group_name> is name of the Crypto group configured in the same context for IPSec Tunnel Failover feature.
|
|
•
|
<map_name1> is name of the preconfigured ISAKMP crypto map to match with crypto group as primary.
|
|
•
|
<map_name2> is name of the preconfigured ISAKMP crypto map to match with crypto group as secondary.
|
DPD is configured at the context level and is used in support of the IPSec Tunnel Failover feature (refer to the Redundant IPSec Tunnel Fail-Over section) and/or to help prevent tunnel state mismatches between an FA and HA when IPSec is used for Mobile IP applications. When used with Mobile IP applications, DPD ensures the availability of tunnels between the FA and HA. (Note that the starIPSECDynTunUp and starIPSECDynTunDown SNMP traps are triggered to indicate tunnel state for the Mobile IP scenario.)
Regardless of the application, DPD must be supported/configured on both security peers. If the system is configured with DPD but it is communicating with a peer that does not have DPD configured, IPSec tunnels still come up. However, the only indication that the remote peer does not support DPD exists in the output of the show crypto isakmp security-associations summary command.
Important: If DPD is enabled while IPSec tunnels are up, it will not take affect until all of the tunnels are cleared.
Important: DPD must be configured in the same context on the system as other IPSec Parameters.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
•
|
<ctxt_name> is the destination context where the Crypto Group is to be configured.
|
Important: This section provides the minimum instruction set for configuring an APN template to support L2TP for APN. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference. To configure the APN to support L2TP:|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <num> ] [ tunnel-context <tunnel_ctxt_name> ] [ local-address <agw_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
|
•
|
<ctxt_name> is the system context in which the APN template is configured.
|
|
•
|
<apn_name> is name of the preconfigured APN template in which you want to configure L2TP support.
|
|
•
|
<lns_address> is IP address of the LNS node to which this APN will communicate.
|
|
•
|
<tunnel_ctxt_name> is the L2TP context in which the L2TP tunnel is configured.
|
|
•
|
<agw_ip_address> is the local IP address of the GGSN in which this APN template is configured.
|
|
•
|
<map_name> is the preconfigured crypto map (ISAKMP or manual) which is to use for L2TP.
|
For more information on ACLs, see the System Administration Guide.
|
•
|
PSK (Pre-Shared Key) Authentication: A pre-shared key is a shared secret that was previously shared between two network nodes. IPSec for LTE/SAE supports PSK such that both IPSec nodes must be configured to use the same shared secret.
|
|
•
|
X.509 Certificate-based Peer Authentication: IPSec for LTE/SAE supports X.509 certificate-based peer authentication and CA (Certificate Authority) certificate authentication as described below.
|
|
•
|
Idle Tunnel Termination: When a session manager for a service detects that all subscriber sessions using a given IPSec tunnel have terminated, the IPSec tunnel also gets terminated after a timeout period.
|
|
•
|
Service Termination: When a service running on a network node is brought down for any reason, all corresponding IPSec tunnels get terminated. This may be caused by the interface for a service going down, a service being stopped manually, or a task handling an IPSec tunnel restarting.
|
|
•
|
Unreachable Peer: If a network node detects an unreachable peer via Dead Peer Detection (DPD), the IPSec tunnel between the nodes gets terminated. DPD can be enabled per P-GW, S-GW, and MME service via the system CLI during crypto template configuration.
|
|
•
|
E-UTRAN Handover Handling: Any IPSec tunnel that becomes unusable due to an E-UTRAN network handover gets terminated, while the network node to which the session is handed initiates a new IPSec tunnel for the session.
|
Appendix I
L2TP Access Concentrator
L2TP Access Concentrator
Important: This product requires the purchase of a separate session licence and feature key in order to function as described.
Important: The LAC service uses UDP ports 13660 through 13668 as the source port for sending packets to the LNS.|
•
|
Attribute-based tunneling: This method is used to encapsulate PPP packets for only specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.
|
|
•
|
PDSN Service-based compulsory tunneling: This method of tunneling is used to encapsulate all incoming PPP traffic from the R-P interface coming into a PDSN service, and tunnel it to an LNS peer for authentication. It should be noted that this method does not consider subscriber configurations, since all authentication is performed by the peer LNS.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.|
Step 1
|
Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
|
|
Step 2
|
Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.
|
|
Step 3
|
Configure the PDSN service(s) with the tunnel context location according to the instructions located in the Modifying PDSN Services for L2TP Support section of this chapter.
|
|
Step 4
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
|
Step 4
|
The PDSN service detects its tunnel-type parameter is configured to L2TP and its tunnel-context parameter is configured to the Destination context.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.|
Step 1
|
Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.
|
|
Step 2
|
Configure the PDSN service(s) according to the instructions located in the Modifying PDSN Services for L2TP Support section of this chapter.
|
|
Step 3
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
|
•
|
Transparent IP: The APN template’s L2TP parameter settings will be applied to the session.
|
|
•
|
Non-transparent IP: Since authentication is required, L2TP parameter attributes in the subscriber profile (if configured) will take precedence over the settings in the APN template.
|
|
•
|
PPP: The APN template’s L2TP parameter settings will be applied and all of the subscriber’s PPP packets will be forwarded to the specified LNS.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a GGSN.|
1.
|
Configure the APN template to support L2TP tunneling according to the information and instructions located in the Modifying APN Templates to Support L2TP section of this chapter.
|
Important: L2TP tunneling can be configured within individual subscriber profiles as opposed/or in addition to configuring support with an APN template. Subscriber profile configuration is described in the Configuring Subscriber Profiles for L2TP Support section of this chapter.|
2.
|
Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.
|
|
3.
|
Save your configuration as described in Verifying and Saving Your Configuration chapter.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as an HA.|
Step 1
|
Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
|
|
Step 2
|
Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.
|
|
Step 3
|
Save your configuration as described in Verifying and Saving Your Configuration chapter.
|
Important: Since the instructions for configuring subscribers differ between RADIUS server applications, this section only provides the individual attributes that can be added to the subscriber profile. Refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.
 Important: If the LAC service and egress interface are configured in the same context as the core service or HA service, this attribute is not needed. |
|||||||||
 Important: This attribute is only used when the loadbalance-tunnel-peers parameter or SN-Tunnel-Load-Balancing attribute configured to prioritized. |
|||||||||
|
|||||||||
Important: The configuration of RADIUS-based subscriber profiles is not discussed in this document. Please refer to the documentation supplied with your RADIUS server for further information.
Important: This section provides the minimum instruction set for configuring local subscriber profile for L2TP support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.|
Step 1
|
Configure the “Local” subscriber with L2TP tunnel parameters and the load balancing parameters with action by applying the example configuration in the Configuring Local Subscriber section.
|
|
Step 2
|
Verify your L2TP configuration by following the steps in the Verifying the L2TP Configuration section.
|
|
Step 3
|
Save your configuration as described in Verifying and Saving Your Configuration chapter.
|
context <ctxt_name> [-noconfirm]
subscriber name <subs_name>
tunnel l2tp peer-address <lns_ip_address> [ preference <integer> | [ encrypted ] secret <secret_string> | tunnel-context <context_name> | local-address <local_ip_address> }
|
•
|
<ctxt_name> is the system context in which you wish to configure the subscriber profile.
|
|
•
|
<lns_ip_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.
|
show subscriber configuration username user_name
Important: Not all commands, keywords and functions may be available. Functionality is dependent on platform and license(s).
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.|
Step 1
|
Configure the LAC service on system and bind it to an IP address by applying the example configuration in the Configuring LAC Service section.
|
|
Step 2
|
Optional. Configure LNS peer information if the Tunnel-Service-Endpoint attribute is not configured in the subscriber profile or PDSN compulsory tunneling is supported by applying the example configuration in the Configuring LNS Peer section.
|
|
Step 4
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
context <dst_ctxt_name> [-noconfirm]
lac-service <service_name>
bind address <ip_address>
|
•
|
<dst_ctxt_name> is the destination context where you want to configure the LAC service.
|
context <dst_ctxt_name> [ -noconfirm ]
lac-service <service_name>
peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> {[encrypted] isakmp-secret <secret> }] [description <text>] [ preference <integer>]
|
•
|
<dst_ctxt_name> is the destination context where the LAC service is configured.
|
show lac-service name service_name
Important: This section provides the minimum instruction set for modifying PDSN service for L2TP support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.|
Step 1
|
|
Step 2
|
Verify your configuration to modify PDSN service by following the steps in the Verifying the PDSN Service for L2TP Support section.
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
context <source_ctxt_name> [ -noconfirm ]
pdsn-service <pdsn_service_name>
ppp tunnel-context <lac_context_name>
|
•
|
<source_ctxt_name> is the name of the source context containing the PDSN service, which you want to modify for L2TP support.
|
|
•
|
<pdsn_service_name> is the name of the pre-configured PDSN service, which you want to modify for L2TP support.
|
|
•
|
<lac_context_name> is typically the destination context where the LAC service is configured.
|
show pdsn-service name pdsn_service_name
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.|
Step 1
|
Modify the APN template to support L2TP with LNS server address and other parameters by applying the example configuration in the Assigning LNS Peer Address in APN Template section.
|
|
Step 2
|
Optional. If L2TP will be used to tunnel transparent IP PDP contexts, configure the APN’s outbound username and password by applying the example configuration in the Configuring Outbound Authentication section.
|
|
Step 3
|
Verify your APN configuration by following the steps in the Verifying the APN Configuration section.
|
|
Step 4
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
context <dst_ctxt_name> [-noconfirm]
apn <apn_name>
tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <integer> ] [ tunnel-context <l2tp_context_name> ] [ local-address <local_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
|
•
|
<dst_ctxt_name> is the name of system destination context in which the APN is configured.
|
|
•
|
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
|
|
•
|
<lns_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.
|
context <dst_ctxt_name> [ -noconfirm ]
apn <apn_name>
|
•
|
<dst_ctxt_name> is the destination context where APN template is is configured.
|
|
•
|
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
|
show apn name apn_name
Appendix J
L2TP Network Server
L2TP Network Server
Important: This product requires that you buy a license and feature use key. Not all features and functions may be functioning on all platforms.
Important: The LNS service uses UDP ports 13660 through 13668 as the source port for receiving packets from the LAC. You can force the LNS to only use the standard L2TP port (UDP Port 1701) with the single-port-mode LNS service configuration mode command. Refer to the Command Line Interface Reference for more information on this command.
|
NOTE: For this configuration, the IP context name should be identical to the name of the destination context.
|
|
|
NOTE: For this configuration, the destination context name should not match the domain name of a specific domain.
|
|
Important: This section provides the minimum instruction set for configuring an LNS service allowing the system to terminate L2TP tunnels and process data sessions. For more information on commands that configure additional LNS service properties, refer LNS Configuration Mode Commands chapter in Command Line Interface Reference.|
Step 1
|
Create the LNS service and bind it to an interface IP address by applying the example configuration in the Creating and Binding LNS Service section.
|
|
Step 2
|
Specify the authentication parameters for LNS service by applying the example configuration in the Configuring Authentication Parameters for LNS Service section.
|
|
Step 3
|
Configure the maximum number of tunnels supported by the LNS service and maximum number of sessions supported per tunnel by applying the example configuration in the Configuring Tunnel and Session Parameters for LNS Service section.
|
|
Step 4
|
Configure peer LACs for the LNS service by applying the example configuration in the Configuring Tunnel and Session Parameters for LNS Service section.
|
|
Step 5
|
Optional. Specify the domain alias designated for the context which the LNS service uses for AAA functionality by applying the example configuration in the Configuring Domain Alias for AAA Subscribers section.
|
|
Step 6
|
Verify your LNS service configuration by following the steps in the Verifying the LNS Service Configuration section.
|
|
Step 7
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
context <dest_ctxt_name> -noconfirm
lns-service <lns_svc_name> -noconfirm
context <dest_ctxt_name>
lns-service <lns_svc_name>
|
•
|
For more information on authentication procedure and priorities, refer authentication command section in LNS Configuration Mode Commands chapter of Command Line Interface Reference.
|
context <dest_ctxt_name>
lns-service <lns_svc_name>
max-tunnel <max_tunnels>
max-session-per-tunnel <max_sessions>
context <dest_ctxt_name>
lns-service <lns_svc_name>
peer-lac { <lac_ip_address> | <ip_address>/<mask> } [ encrypted ] secret <secret_string> [ description <desc_text> ]
context <dest_ctxt_name> -noconfirm
lns-service <lns_svc_name> -noconfirm
nai-construct domain <domain_alias>
Important: This command should only be used if the LNS service is configured to allow “no authentication” using the authentication allow-noauth command.show lns-service name service_name
Appendix K
Mobile IP Registration Revocation
Mobile IP Registration Revocation
Important: This license is enabled by default; however, not all features are supported on all platforms and other licenses may be required for full functionality as described in this chapter.
Important: Registration Revocation functionality is also supported for Proxy Mobile IP. However, only the HA can initiate the revocation for Proxy-MIP calls.
Important: The Revocation Support Extension in the RRQ or RRP must be protected by the FA-HA Authentication Extension. Therefore, an FA-HA SPI must be configured at the FA and the HA for this to succeed.|
•
|
FA service(s): Registration Revocation must be enabled and operational parameters optionally configured.
|
|
•
|
HA service(s): Registration Revocation must be enabled and operational parameters optionally configured.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions for a core network service with FA and/or an HA according to the instructions described in the respective product Administration Guide.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.Save your configuration as described in Saving Your Configuration.
Save your configuration as described in Saving Your Configuration.
Appendix L
Multimedia Broadcast and Multicast Service
Multimedia Broadcast and Multicast Service
Important: The features described in this chapter are only available if you have purchased and installed MBMS feature support license on your chassis.|
•
|
Important: The ASR 5000 platform supports 225 downlink SGSNs per MBMS Bearer Service through NPU assisted data flow processing. NPU assisted data processing is available on ASR 5000 platforms with release 8.1 or later only.
|
•
|
Important: For capacity and resource purpose one MBMS UE context is equal to one PDP context.
Important: These instructions assume that you have already configured the GGSN/SGSN system level configuration as described in network function Administration Guide.|
Step 1
|
Configure the BM-SC profile in a context by applying the example configurations presented in the BMSC Profile Configuration section.
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
|
Step 5
|
Save the changes to system configuration by applying the example configuration found in Verifying and Saving Your Configuration chapter.
|
|
Step 6
|
Verify configuration of MBMS service related parameters by applying the commands provided in the Managing Your Configuration section of this chapter.
|
gmb diameter peer-select peer < peer_name> [ realm <realm_name> ] [ secondary-peer <sec_peer_name> [ realm <sec_realm_name> ]]
To save changes made to the system configuration for this service, refer Verifying and Saving Your Configuration chapter.
This section explains how to display and review the configurations after saving them in a .cfg file as described in Saving Your Configuration chapter of this guide and also to retrieve errors and warnings within an active configuration for a service.
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.Output descriptions for most of the commands are located in Command Line Interface Reference.
Important: All commands listed here are under Exec mode. For more information on these commands, refer Executive Mode Commands chapter in Command Line Interface Reference.|
show mbms bearer-service [ mcast-address <mcast_address> ] [ apn <apn_name> ] [ bmsc-profile <bmsc_profile_name> ] [ service-type { multicast | broadcast } ] [ summary | full ] [ all ]
|
||
Important: This release provides BGP/MPLS VPN for directly connected PE routers only.|
•
|
|
•
|
|
•
|
The system in this scenario uses static/dynamic MPLS labels for ingress and egress traffic. For configuration information on static label, refer to the Configuring BGP/MPLS VPN with Static Labels section and refer Configuring BGPMPLS VPN with Dynamic Labels for dynamic lable configuration.
Important: MPLS ping/trace route debugging facilities are not supported.
The system in this scenario uses static/dynamic MPLS labels for ingress and egress traffic. For configuration information on static label, refer to the Configuring BGP/MPLS VPN with Static Labels section and refer Configuring BGPMPLS VPN with Dynamic Labels for dynamic lable configuration.
Important: One or mor esections of above mentioned IETF are partially supported for this feature. For more information on Statement of Compliance, contact local represntative.|
•
|
Cisco PID [ ASR5K-00-CS01MPLS ] MPLS License, 1K Sessions, or Starent Part Number [ 600-00-7579 ] MPLS License, 1K Sessions.
|
|
•
|
Cisco PID [ ASR5K-00-CS10MPLS ] MPLS License, 10K Sessions, or Starent Part Number [ 600-20-0041 ] MPLS License, 10K Sessions.
|
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
The base configuration, as described in the Routing chapter in this guide, must be completed prior to attempt the configuration procedure described below.
Important: The features described in this chapter is an enhanced feature and need enhanced feature license. This support is only available if you have purchased and installed particular feature support license on your chassis.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.|
Step 1
|
Create a VRF on the router and assign a VRF name by applying the example configuration in the Create VRF with Route-distinguisher and Route-target section.
|
|
Step 2
|
Set the neighbors and address family to exchange routing information and establish BGP peering with a peer router by applying the example configuration in the Set Neighbors and Enable VPNv4 Route Exchange section.
|
|
Step 3
|
Configure the address family and redistribute the connected routes domains into BGP by applying the example configuration in the Configure Address Family and Redistribute Connected Routes section. This takes any routes from another protocol and redistributes them to BGP neighbors using the BGP protocol.
|
|
Step 4
|
Configure IP Pools with MPLS labels for input and output by applying the example configuration in the Configure IP Pools with MPLS Labels section.
|
|
Step 5
|
Optional. Bind DHCP service to work with MPLS labels for input and output in corporate networks by applying the example configuration in the Bind DHCP Service for Corporate Servers section.
|
|
Step 6
|
Optional. Bind AAA/RADIUS server group in corporate network to work with MPLS labels for input and output by applying the example configuration in the Bind AAA Group for Corporate Servers section.
|
|
Step 7
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.
|
Use this example to first create a VRF on the router and assign a VRF name. The second ip vrf command creates the route-distinguisher and route-target.
Use this example to configure the address-family and to redistribute the connected routes or IP pools into BGP. This takes any routes from another protocol and redistributes them using the BGP protocol.
ip pool <name> <ip_addr_mask_combo> private vrf <vrf_name> mpls-label input <in_label_value> output <out_label_value1> nexthop-forwarding-address <ip_addr_bgp_neighbor>
bind address <bind_ip_address> [ nexthop-forwarding-address <nexthop_ip_address> [ mpls-label input <in_mpls_label_value> output <out_mpls_label_value1> [ <out_mpls_label_value2> ]]]
|
•
|
Optional keyword nexthop-forwarding-address <ip_address> mpls-label input <in_mpls_label_value> output < <out_mpls_label_value1> applies DHCP over MPLS traffic.
|
radius attribute nas-ip-address address <nas_address> nexthop-forwarding-address <ip_address> mpls-label input <in_mpls_label_value> output < <out_mpls_label_value1>
|
•
|
aaa_grp_name is a pre-configured AAA server group configured in Context Configuration mode. Refer AAA Interface Administration Reference for more information on AAA group configuration.
|
|
•
|
Optional keyword nexthop-forwarding-address <ip_address> mpls-label input <in_mpls_label_value> output < <out_mpls_label_value1> associates AAA group for MPLS traffic.
|
The base configuration, as described in the Routing chapter in this guide, must be completed prior to attempt the configuration procedure described below.
Important: The features described in this chapter is an enhanced feature and need enhanced feature license. This support is only available if you have purchased and installed particular feature support license on your chassis.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.|
Step 1
|
Create a VRF on the router and assign a VRF name by applying the example configuration in the Create VRF with Route-distinguisher and Route-target section.
|
|
Step 2
|
Set the neighbors and address family to exchange routing information and establish BGP peering with a peer router by applying the example configuration in the Set Neighbors and Enable VPNv4 Route Exchange section.
|
|
Step 3
|
Configure the address family and redistribute the connected routes domains into BGP by applying the example configuration in the Configure Address Family and Redistribute Connected Routes section. This takes any routes from another protocol and redistributes them to BGP neighbors using the BGP protocol.
|
|
Step 4
|
|
Step 5
|
Optional. Bind DHCP service to work with dynamic MPLS labels in corporate networks by applying the example configuration in the Bind DHCP Service for Corporate Servers section.
|
|
Step 6
|
Optional. Bind AAA/RADIUS server group in corporate network to work with dynamic MPLS labels by applying the example configuration in the Bind AAA Group for Corporate Servers section.
|
|
Step 7
|
Optional. Modify the configured IP VRF, which is configured to support basic MPLS functionality, for mapping between DSCP bit value and experimental (EXP) bit value in MPLS header for ingress and egress traffic by applying the example configuration in the DSCP and EXP Bit Mapping section.
|
|
Step 8
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.
|
Use this example to first create a VRF on the router and assign a VRF name. The second ip vrf command creates the route-distinguisher and route-target.
|
•
|
If export and improt route targets are the same, alternate command route-target both {<as_value> | <ip_address> } <rt_value> can be used in place of route-target import and route-target export commands.
|
Use this example to configure the address-family and to redistribute the connected routes or IP pools into BGP. This takes any routes from another protocol and redistributes them using the BGP protocol.
|
•
|
aaa_grp_name is a pre-configured AAA server group configured in Context Configuration mode. Refer AAA Interface Administration Reference for more information on AAA group configuration.
|
|
•
|
[local]host_name#
[local]host_name(config)#
context <context_name>
context_name is the name of the destination context where the HA service is configured. The name must be from 1 to 63 alpha and/or numeric characters and is case sensitive.The following prompt appears:
ha-service <ha_service_name>
ha_service_name is the name of the HA service. The name must be from 1 to 63 alpha and/or numeric characters and is case sensitive.The following prompt appears:
policy nw-reachability-fail { reject [ use-reject-code { admin-prohibited | insufficient-resources } ] | redirect <ip_addr1> [ weight <value> ] [ <ip_addr2> [ weight <value> ] ] ... [ <ip_addr16> [ weight <value> ] ] }
|
redirect <ip_addr1> [ weight <value> ] [ <ip_addr2> [ weight <value> ] ] ... [ <ip_addr16> [ weight <value> ] ]
|
<ip_addr>: This must be an IPv4 address. Up to 16 IP addresses and optional weight values can be entered on one command line.
weight <value>: When multiple addresses are specified, they are selected in a weighted round-robin scheme. If a weight is not specified, the entry is automatically assigned a weight of 1. <value> must be an integer from 1 through 10.
|
nw-reachability server <server_name> [ interval <seconds> ] [ local-addr <ip_addr> ] [ num-retry <num> ] [ remote-addr <ip_addr> ] [ timeout < seconds> ]
|
interval <seconds>
|
Specifies the frequency in seconds for sending ping requests.<seconds> must be an integer from 1 through 3600.
|
|
local-addr <ip_addr>
|
|
|
num-retry <num>
|
Specifies the number of retries before deciding that there is a network-failure. <num> must be an integer from 0 through 100.
|
|
remote-addr <ip_addr>
|
|
|
timeout < seconds>
|
Specifies how long to wait, in seconds, before retransmitting a ping request to the remote address. <seconds> must be an integer from 1 through 10.
|
|
•
|
Repeat step 6 to configure additional network reachability servers.
|
|
•
|
To bind a network reachability server to an IP pool, continue with step 9. To bind a network reachability server to a local subscriber profile, skip to step 11.
|
|
<pool_name>
|
|
|
nw-reachability server <server_name>
|
<server_name>: The name of a network reachability server that has been defined in the current context. This is a string of from 1 through 16 characters.
|
|
•
|
subscriber { default | name <subs_name> }
Where default is the default subscriber for the current context and subs_name is the name of the subscriber profile that you want to configure for network reachability.The following prompt appears:
nw-reachability server <server_name>
Where server_name is the name of a network reachability server that has been defined in the current context.
[local]host_name#
context <context_name>
Where context_name is the name of the destination context for which you configured network reachability.The following prompt appears:
show ha-service name <ha_service_name>
Where <ha_service_name> is the name of the HA service in the current context for which you configured a network reachability policy.The output of this command includes information about the network reachability policy that looks similar to the following:
show ip pool pool-name <pool_name>
Where <pool_name> is the name of the IP pool to which you bound a network reachability server name.The output of this command includes information about the network reachability server name that looks similar to the following:
show subscribers configuration username <subscriber_name>
Where <subscriber_name> is the name of the local subscriber to which you bound a network reachability server name.The output of this command includes information about the network reachability server name that looks similar to the following:
|
•
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
The SN-Nw-Reachability-Server-Name attribute is contained in the following dictionaries:
|
•
|
The SN1-Nw-Reachability-Server-Name attribute is contained in the following dictionaries:
Refer to the AAA Interface Administration and Reference for more details.
Appendix O
Policy Forwarding
Policy Forwarding
|
•
|
For more information on creating IP pools, refer to the System Administration Guide and for additional information on the ip pool command, refer to the Command Line Interface Reference.
context <context_name>
Save the configuration as described in the Saving Your Configuration chapter.
context <context_name>
nexthop-forwarding-address <forwarding_ip_address>
Save the configuration as described in the Saving Your Configuration chapter.
Important: Refer to Access Control Lists for additional information on creating and using ACLs. context <context_name>
ip access-list <acl_name>
The following example specifies that any IP packet coming from any system on the 192.168.55.0 network that has a destination host address of 192.168.80.1 is to be redirected, or forwarded, through the system interface named interface2 to the host at 192.168.23.12:
Save the configuration as described in the Saving Your Configuration chapter.
To apply the ACL to the IP access group for the current destination context, go to Applying the ACL to a Destination Context.
To apply the ACL to the IP access group for an interface in the current destination context, go to Applying the ACL to an Interface in a Destination Context .
|
Step 2
|
Save the configuration as described in the Saving Your Configuration chapter.
|
context <context_name>
interface <interface_name>
ip access-group <acl_name> in <priority-value>
context <context_name>
interface <interface_name>
|
Step 3
|
Save the configuration as described in the Saving Your Configuration chapter.
|
Appendix P
Proxy-Mobile IP
Proxy-Mobile IP
|
•
|
Important: This feature is enabled as part of a license bundle or with the purchase of a standalone Proxy-MIP license. Other licenses might be required to enable all the features described in this chapter. If you do not have the appropriate license(s), please contact your sales advisor.|
•
|
Scenario 1: The AAA server that authenticates the MN at the PDSN allocates an IP address to the MN. Note that the PDSN does not allocate an address from its IP pools.
|
|
•
|
Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.
|
|
•
|
Scenario 1: The AAA server that authenticates the MN at the ASN GW allocates an IP address to the MN. Note that the ASN GW does not allocate an address from its IP pools.
|
|
•
|
Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.
|
|
a. If PDIF service does not support Multiple-Authentication and ANOTHER_AUTH_FOLLOWS Notify payload is received, then PDIF sends IKE_AUTH Response with appropriate error and terminate the IKEv2 session by sending INFORMATIONAL (Delete) Request.b. If ANOTHER_AUTH_FOLLOWS Notify payload is not present in the IKE_AUTH Request, PDIF allocates the IP address from the locally configured pools. However, if proxy-mip-required is enabled, then PDIF initiates Proxy-MIP setup to HA by sending P-MIP RRQ. When PDIF receives the Proxy-MIP RRP, it takes the Home Address (and DNS addresses if any) and sends the IKE_AUTH Response back to MS by including CP payload with Home Address and DNS addresses. In either case, IKEv2 setup will finish at this stage and IPSec tunnel gets established with a Tunnel Inner Address (TIA).
|
|
|
PDIF checks the validity of the AUTH payload and initiates Proxy-MIP setup request to the Home Agent if proxy-mip-required is enabled. The HA address may be received from the RADIUS server in the Access Accept (Step 16) or may be locally configured. PDIF may also remember the HA address from the first authentication received in the final DEA message.
|
|
|
If proxy-mip-required is disabled, PDIF assigns the IP address from the local pool.
|
|
Important: For Proxy-MIP call setup using PAP, the first 14 steps are the same as for CHAP authentication. However, here they deviate because the MS does not support EAP-MD5 authentication, but EAP-GTC. In response to the EAP-MD5 challenge, the MS instead responds with legacy-Nak with EAP-GTC. The diagram below picks up at this point.
Important: Not all commands and keywords/variables may be supported. This depends on the platform type and the installed license(s).|
•
|
FA service(s): Proxy Mobile IP must be enabled, operation parameters must be configured, and FA-HA security associations must be specified.
|
|
•
|
HA service(s): FA-HA security associations must be specified.
|
|
•
|
Subscriber profile(s): Attributes must be configured to allow the subscriber(s) to use Proxy Mobile IP. These attributes can be configured in subscriber profiles stored locally on the system or remotely on a RADIUS AAA server.
|
|
•
|
APN template(s): Proxy Mobile IP can be supported for every subscriber IP PDP context facilitated by a specific APN template based on the configuration of the APN.
|
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a core network service and/or an HA according to the instructions described in the respective product administration guide. fa-ha-spi remote-address { ha_ip_address | ip_addr_mask_combo } spi-number number { encrypted secret enc_secret | secret secret } [ description string ][ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } | replay-protection { timestamp | nonce } | timestamp-tolerance tolerance ]
|
•
|
The proxy-mip max-retransmissions command configures the maximum number re-try attempts that the FA service is allowed to make when sending Proxy Mobile IP Registration Requests to the HA.
|
|
•
|
proxy-mip retransmission-timeout configures the maximum amount of time allowed by the FA for a response from the HA before re-sending a Proxy Mobile IP Registration Request message.
|
|
•
|
proxy-mip renew-percent-time configures the amount of time that must pass prior to the FA sending a Proxy Mobile IP Registration Renewal Request.
|
If the advertisement registration lifetime configured for the FA service is 900 seconds and the renew-time is configured to 50%, then the FA requests a lifetime of 900 seconds in the Proxy MIP registration request. If the HA grants a lifetime of 600 seconds, then the FA sends the Proxy Mobile IP Registration Renewal Request message after 300 seconds have passed.
|
•
|
Use the fa-ha-spi remote-addresscommand to modify configured FA-HA SPIs to support Proxy Mobile IP. Refer to the Command Line Interface Reference for the full command syntax.
|
Important: Note that FA-HA SPIs must be configured for the Proxy-MIP feature to work, while it is optional for regular MIP.|
•
|
Use the authentication mn-ha allow-noauth command to configure the FA service to allow communications from the HA without authenticating the HA.
|
show fa-service name <fa_service_name>
|
•
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
Proceed to the optional Configuring Proxy MIP HA Failover section to configure Proxy MIP HA Failover support or skip to the Configuring HA Services section to configure HA service support for Proxy Mobile IP.
Important: This configuration in this section is optional. proxy-mip ha-failover [ max-attempts <max_attempts> | num-attempts-before-switching <num_attempts> | timeout <seconds> ]
|
•
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
Important: Note that FA-HA SPIs must be configured for the Proxy MIP feature to work while it is optional for regular MIP. Also note that the above syntax assumes that FA-HA SPIs were previously configured as part of the HA service as described in respective product Administration Guide. The replay-protection and timestamp- tolerance keywords should only be configured when supporting Proxy Mobile IP. fa-ha-spi remote-address <fa_ip_address> spi-number <number> { encrypted secret <enc_secret> | secret <secret> } [ description <string> ] [ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } ] replay-protection { timestamp | nonce } | timestamp-tolerance <tolerance> ]
|
•
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
context <context_name>
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.|
For Proxy Mobile IP, this attribute must be set to Simple IP.
|
|
|||||
|
This attribute must be enabled to support Proxy Mobile IP.
|
|
|||||
 Important: Regardless of the configuration of this attribute, the FA facilitating the Proxy Mobile IP session will not allow simultaneous Simple IP and Mobile IP sessions for the MN. |
||||||
show subscribers configuration username <subscriber_name>
|
•
|
Optional: If you have enabled the Proxy-MIP HA Failover feature, use the mobile-ip home-agent ha_address alternate command to specify the secondary, or alternate HA.
|
|
•
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
subscriber_name is the name of the subscriber and can be from 1 to 127 alpha and/or numeric characters and is case sensitive.
Save your configuration as described in Verifying and Saving Your Configuration.
Important: This is an optional configuration. In addition, attributes returned from the subscriber’s profile for non-transparent IP PDP contexts take precedence over the configuration of the APN.[local]host_name#
[local]host_name(config)#
context <context_name>
context_name is the name of the system destination context designated for APN configuration. The name must be from 1 to 79 alpha and/or numeric characters and is case sensitive.The following prompt appears:
apn <apn_name>
apn_name is the name of the APN that is being configured. The name must be from 1 to 62 alpha and/or numeric characters and is not case sensitive. It may also contain dots (.) and/or dashes (-).The following prompt appears:
|
Step 5
|
Optional. GGSN/FA MN-NAI extension can be skipped in MIP Registration Request by entering following command:
|
[local]host_name#
|
Step 7
|
show apn { all | name <apn_name> }
|
Step 9
|
Save your configuration as described in Verifying and Saving Your Configuration.
|
Appendix Q
QoS Management
QoS Management
The QoS Traffic Policing functionality supported by the GGSN implements QoS for subscribers based on the configuration of the APN template used as described in Traffic Policing and Shaping in this guide. As a result, all subscriber PDP contexts using the APN receive the same QoS level. This could lead to unused or under-utilized bandwidth by some subscribers and thus reducing the amount of resources available to others.
Important: For L7 traffic analysis ECSv2 license is required.
Important: For L7 traffic analysis ECSv2 license is required.
Important: For L7 traffic analysis ECSv2 license is required.|
2.
|
As the subscriber starts using some applications, the traffic gets classified on the basis of type of data packets or traffic as mentioned in section Classification of Application Traffic and accordingly the corresponding bit in Traffic-class-bitfield get set.
|
Warning: This feature does not work in conjunction with IMS-Authorization service.
Important: The packet that triggers the NRUPC request is discarded.
Important: The packet that triggers the NRSPCA request is discarded.
Important: The packet that triggers the NRUPC/NRSPCA request is discarded.
Caution: For Dynamic QoS Renegotiation, two RADIUS attributes are required for remote subscriber configuration. For a particular subscriber, these attributes can be overridden without considering the timeout for Dynamic QoS Renegotiation and whether Dynamic QoS Renegotiation is enabled or not.|
Step 1
|
|
Step 2
|
|
Step 3
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
Step 4
|
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands. context <context_name>
ip access-list <acl_name>
|
•
|
<context_name> must be the name of the destination context in which you want to configure the ACL. The same context must be used for APN configuration.
|
active-charging service <service_name>
flow limit-for-bandwidth direction downlink peak-data-rate <bps> peak-burst-size <bytes> violate-action lower-ip-precedence
|
•
|
The flow limit-for-bandwidth command contains other option than the example shown here. Refer ti the ACS Charging Action Configuration Mode Commands chapter in the Command Line Interface Reference for more information on this command.
|
active-charging service <service_name>
qos-renegotiate timeout <timeout>
context <context_name>
apn <apn_name>
|
•
|
<context_name> must be the name of the destination context in which you have already configured the ACL, and want to configure the APN template.
|
|
•
|
<acl_name> must be the name of the ACL that you have already configured in the context.
|
|
•
|
If in the ip access-group command of the APN Configuration Mode, the optional in or out keywords are not specified, the ACL will be applied to all packets, in and out.
|
|
Step 1
|
|
Step 2
|
|
Step 3
|
|
Step 4
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
|
Step 5
|
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands. active-charging service <service_name>
ip remote-address { = { <ip_address> | <ip_address/mask> } | { range { <ip_address> | <ip_address/mask> } to { <ip_address> | <ip_address/mask> } }
priority <priority>
active-charging service <service_name>
qos-class-identifier <identifier>
tft packet-filter <filter_name>
flow limit-for-bandwidth direction { downlink | uplink } peak-data-rate <bps> peak-burst-size <bytes> violate-action { discard | lower-ip-precedence }
|
•
|
A number of optional keywords and variable are available for the flow limit-for-bandwidth direction command. Refer to the Command Line Interface Reference for more information regarding this command.
|
context <context_name>
apn <apn_name>
|
•
|
show apn name <apn_name>
apn_name must be the name of the APN configured in the Configuring APNs for Dynamic QoS Renegotiation section.The output of this command displays the APN’s configuration. Examine the output for the ip output access-group and ip input access-group fields. For more details refer to the Applying a Single ACL to Multiple Subscribers section in this guide.
show ip access-list <acl_name>
The RADIUS attributes listed in the following table are used to configure Dynamic QoS Renegotiation for subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA and GTPP Interface Administration and Reference.
Appendix R
Remote Address-based RADIUS Accounting
Remote Address-based RADIUS Accounting
|
•
|
Cisco PID [ ASR5K-00-CS01DBAC ] Destination Based Accounting,1K sessions, or Starent Part Number [ 600-00-7510 ] Destination Based Accounting.
For information on obtaining and installing licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the Cisco ASR 5000 Series System Administration Guide.
context <context_name>
radius group <group_name>
radius accounting ip remote-address list <list_id>
show configuration context <context_name>
context <context_name>
|
•
|
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
|
Important: Since the instructions for configuring subscribers differ between RADIUS server applications, this section only provides the individual attributes that can be added to the subscriber profile. Please refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.The following RADIUS attributes are used to configure remote address-based RADIUS accounting for a subscriber session. For specific information on each attribute, see the Cisco ASR 5000 Series AAA and GTP Interface Administration and Reference.
context <context_name>
subscriber name <name>
context <context_name>
|
•
|
Save your configuration as described in Verifying and Saving Your Configuration chapter.
|
Appendix S
Subscriber Overcharging Protection
Subscriber Overcharging Protection
Important: The feature described in this chapter is an enhanced feature and implementation may require a feature license. Refer to your product’s administration guide or ask your Cisco account representative for more information about feature licensing.
Important: This section provides the minimum instruction set to configure the GGSN to avoid the overcharging due to loss of radio coverage in UMTS network. For this feature to be operational, you must also implement the configuration indicated in the section Overcharging Protection - SGSN Configuration also in this chapter. Commands that configure additional function for this feature are provided in the Cisco ASR 5000 Series Command Line Interface Reference.These instructions assume that you have already configured the system-level configuration as described in Cisco ASR 5000 Series System Administration Guide and the Cisco ASR 5000 Gateway GPRS Support Node Administration Guide.
|
Step 1
|
Configure the GTP-C private extension in a GGSN service by applying the example configurations presented in the GTP-C Private Extension Configuration section below.
|
|
Step 2
|
Save the changes to a configuration .cfg file by applying the example configuration found in Saving the Configuration section of the Verifying and Saving Your Configuration chapter in this book.
|
|
Step 3
|
Verify configuration of overcharging protection on LORC related parameters by applying the commands provided in the Verifying Your GGSN Configuration section in this chapter.
|
|
•
|
<vpn_context_name> is the name of the system context where specific GGSN service is configured. For more information, refer Cisco ASR 5000 Gateway GPRS Support Node Administration Guide.
|
|
•
|
<ggsn_svc_name> is name of the GGSN service where you want to enable the overcharging protection for subscribers due to LORC.
|
This section explains how to display and review the configurations after saving them in a .cfg file (as described in the Verifying and Saving Your Configuration chapter in this book) and how to retrieve errors and warnings within an active configuration for a service.
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.show ggsn-service name ggsn_svc_name
The output of this command displays the configuration for overcharging protection configured in the GGSN service ggsn_svc_name.
Important: This section provides a minimum instruction set to configure the SGSN to implement this feature. For this feature to be operational, you must also implement the configuration indicated in the section Overcharging Protection - GGSN Configuration also in this chapter.Command details can be found in the Cisco ASR 5000 Series Command Line Interface Reference.
|
•
|
the system-level configuration as described in the Cisco ASR 5000 Series System Administration Guide,
|
|
•
|
the SGSN service configuration as described in the Cisco ASR 5000 Serving GPRS Support Node Administration Guide, and
|
|
•
|
the configuration of an APN profile as described in the Operator Policy chapter in this guide.
|
|
Step 1
|
Configure the private extension IE with LORC in an APN profile by applying the example configurations presented in the Private Extension IE Configuration section.
|
Important: An APN profile is a component of the Operator Policy feature implementation. To implement this feature, an APN profile must be created and associated with an operator policy. For details, refer to the Operator Policy chapter in this book.|
Step 2
|
Configure the RANAP cause that should trigger this UPCQ message by applying the example configurations presented in the RANAP Cause Trigger Configuration section.
|
|
Step 3
|
Save the changes to a configuration .cfg file by applying the example configuration found in the Saving the Configuration section of the Verifying and Saving Your Configuration chapter in this book.
|
|
Step 4
|
Verify the SGSN portion of the configuration for overcharging protection on LORC related parameters by applying the commands provided in the Verifying the Feature Configuration section.
|
|
•
|
<apn_profile_name> is the name of a previously configured APN profile. For more information, refer to the Operator Policy chapter, also in this book.
|
context <context_name>
iups-service <iups_service_name>
loss-of-radio-coverage ranap-cause <cause> end
|
•
|
<context_name> is the name of the previously configured context in which the IuPS service has been configured.
|
|
•
|
<cause> is an integer from 1 to 512 (the range of reasons is a part of the set defined by 3GPP TS 25.413) that allows configuration of the RANAP Iu release cause code to be included in messages. Default is 46 (MS/UE radio connection lost).
|
This section explains how to display the configurations after saving them in a .cfg file as described in the Verifying and Saving Your Configuration chapter elsewhere in this guide.
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.show apn-profile full name apn_profile_name
|
Step 2
|
show iups-service name <iups_service_name>
Appendix T
Traffic Policing and Shaping
Traffic Policing and Shaping
|
•
|
|
•
|
Committed Data Rate (CDR): The guaranteed rate (in bits per second) at which packets can be transmitted/received for the subscriber during the sampling interval.
|
|
•
|
Peak Data Rate (PDR): The maximum rate (in bits per second) that subscriber packets can be transmitted/received for the subscriber during the sampling interval.
|
|
•
|
Burst-size: The maximum number of bytes that can be transmitted/received for the subscriber during the sampling interval for both committed (CBS) and peak (PBS) rate conditions. This represents the maximum number of tokens that can be placed in the subscriber’s “bucket”. Note that the committed burst size (CBS) equals the peak burst size (PBS) for each subscriber.
|
|
•
|
Drop: The offending packet is discarded.
|
|
•
|
Transmit: The offending packet is passed.
|
|
•
|
Lower the IP Precedence: The packet’s ToS bit is set to “0”, thus downgrading it to Best Effort, prior to passing the packet. Note that if the packet’s ToS bit was already set to “0”, this action is equivalent to “Transmit”.
|
Important: In 3GPP service attributes received from the RADIUS server supersede the settings in the APN.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information. context <context_name>
subscriber name <user_name>
context <context_name>
subscriber name <user_name>
|
•
|
There are numerous keyword options associated with the qos traffic-police direction { downlink | uplink } command.
|
Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.context <context_name>
show subscriber configuration username <user_name>
|
Step 3
|
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
|
context <context_name>
apn <apn_name>
context <context_name>
apn <apn_name>
|
•
|
There are numerous keyword options associated with qos rate-limit { downlink | uplink } command.
|
|
•
|
Optionally, configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:
|
Important: If a “subscribed” traffic class is received, the system changes the class to background and sets the following: The uplink and downlink guaranteed data rates are set to 0. If the received uplink or downlink data rates are 0 and traffic policing is disabled, the default of 64 kbps is used. When enabled, the APN configured values are used. If the configured value for downlink max data rate is larger than can fit in an R4 QoS profile, the default of 64 kbps is used. If either the received uplink or downlink max data rates is non-zero, traffic policing is employed if enabled for the background class. The received values are used for responses when traffic policing is disabled.show apn { all | name <apn_name> }
|
Step 3
|
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
|
Important: In 3GPP, service attributes received from the RADIUS server supersede the settings in the APN.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information. context <context_name>
subscriber name <user_name>
context <context_name>
subscriber name <user_name>
|
•
|
There are numerous keyword options associated with qos traffic-shape direction { downlink | uplink } command.
|
Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.context <context_name>
show subscriber configuration username <user_name>
|
Step 3
|
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
|
context <context_name>
subscriber name <user_name>
context <context_name>
apn <apn_name>
|
Step 2
|
Optional. Configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:
|
context <context_name>
apn <apn_name>
|
•
|
There are numerous keyword options associated with qos rate-limit direction { downlink | uplink } command.
|
For more information on commands, refer Command Line Interface Reference
|
•
|
If the exceed/violate action is set to lower-ip-precedence, this command may override the configuration of the ip qos-dscp command in the GGSN service configuration mode for packets from the GGSN to the SGSN. In addition, the GGSN service ip qos-dscp command configuration can override the APN setting for packets from the GGSN to the Internet. Therefore, it is recommended that command not be used in conjunction with this action.
|
show apn { all | name <apn_name> }
|
Step 4
|
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
|
The RADIUS attributes listed in the following table are used to configure Traffic Policing for CDMA subscribers (PDSN, HA) configured on remote RADIUS servers. More information on these attributes can be found in the AAA Interface Administration and Reference.
|
NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
|
|
|
NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
|
|
The RADIUS attributes listed in the following table are used to configure Traffic Policing for UMTS subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Interface Administration and Reference.
